Model-driven architecture (MDA) can dramatically increase the efficiency of software projects and the quality of produced software. Model transformation technologies play a key role in MDA automation. Technologies that help transform a model from one language to another, or from one level of abstraction to the next, are in demand by any organization looking to adopt MDA. This application of model transformations is referred to as forward engineering. Other applications that are not discussed here include reverse engineering of high level models from lower level models, creating query-based views of a system and performing model refactoring.
Unfortunately, model-to-model transformations are inherently complex to author. The complexity derives from two sources: obviously the transformation problem domain but also the transformation solution domain. The larger and more complicated the modeling languages, the more effort it takes to author their transformations. However, the technology used in realizing a transformation can also have a profound effect on the authoring effort in terms of time and resources required.
There has been a tremendous interest in model-to-model transformation technologies over the past few years; in particular since the OMG (Object Management Group) announced its call for standardization that has resulted in the adoption of the Query-View-Transform (QVT) specifications. Since then, a large number of approaches have been proposed and several were either prototyped or commercialized. However, there has not been much experience with applying most of those approaches in practice. A good categorization of those approaches, outlined in this section, is given in more details in K. Czarnecki and S. Helsen., “Feature-based Survery of Model Transformation Approaches”, IBM Systems Journal, vol. 45, number 3, pages 612-646 (2006). Other surveys are given in T. Gardner, C. Griffin, J. Koehler, and R. Hauser, “A Review of OMG MOF 2.0 Query/Views/Transformations Submissions and Recommendations toward the Final Standard,” OMG Document ad/03-08-02; and S. Sendall and W. Kozaczynski, “Model Transformation: The Heart and Soul of Model-Driven Software Development,” IEEE Software 20, No. 5, pages 42-45, (2003).
One category of approaches to model transformations encompasses pure imperative ones, where an object-oriented framework in some programming language (e.g. Java) offers basic infrastructure to help organize the transformation. That infrastructure consists mainly of APIs and a design pattern with several abstract classes to be implemented by concrete extenders. However, those extenders are left to implement some major strategies like traceability and application control on their own. An example of such an approach is the Transformation Service framework provided in the RSx family of modeling products (P. Swithinbank, M. Chessell, T. Gardner, C. Griffin, J. Man, H. Wylie and L. Yusuf, “Patterns: Model-Driven Development Using IBM Rational Software Architect,” (Section 9.5.2). IBM Redbooks at www.redbooks.ibm.com/redbooks/pdfs/sg247105.pdf). The transformation imperative logic in RSx is done using the Java Metadata Interface (JMI) generated by the EMF framework for domain-specific languages (DSL).
Another category of imperative approach uses higher level dedicated model manipulating languages (e.g. an imperative extension of OCL—Object Constraint Language). A typical approach in this category allows a mapping rule to be specified as an operation on a model element. An operation declares its input type and output type and then the body has imperative logic that populates the attributes of the output type. An example of an approach in this category is the QVT Operational language.
A different category of approaches have the transformation specifications guided with the structure of the target DSL (Domain Specific Language). Approaches in this category have two phases: one for creating the structure (containment hierarchy) of the target model and another for initializing the attributes and connecting the cross-references. Transform authors do not need to explicitly specify scheduling or application strategies as they can automatically be inferred. One approach in this category is the OMG Interactive Objects and Project Technology, which structures the transformation rules into a containment hierarchy based on the one implied by the target domain. There is one rule for every target element type and the application strategy creates the target model top down by traversing down the rule hierarchy. Another example is OptimalJ by Compuware, where transformations are structured using source-to-target copy methods whose parameters' types determine the input domains and whose return type determines the output domain. The framework is able to determine, based on method signatures, the complete application strategy.
Another interesting category is template-based. Approaches in this category specify model transformations using output model templates with variable sections that contain logic to derive their values from input models. A common way to define those variable sections is through annotations expressed using the syntax of the target modeling language. For example, the Ecore language allows for annotating models with user-defined annotations. The derivation logic within annotations can be expressed in any query-based language like OCL. An example of approaches in this category is given in K. Czarnecki and M. Antkiewicz, “Mapping Features to Models: A Template Approach Based on Superimposed Variants,” Proc. of the 4th International Conference on Generative Programming and Component Engineering, Tallinn, Estonia (2005), pp. 422-437, where a UML (Unified Modeling Language) model can be templatized with specific stereotypes applied to UML elements. These stereotypes contain conditions, iterations and other expressions used when instantiating the template.
Furthermore, relational approaches represent another category, where the transformation logic is expressed declaratively using mathematical relationships. The main idea is to declaratively specify mappings between input and output domains using constraints expressed in some sort of mathematical logic. An inference engine is then provided to determine a strategy for applying these rules through a process of constraint solving. In contrast to imperative approaches, relational approaches are side-effect free and can usually support reversible transformations. Examples in this category include MTF (C. Griffin, “IBM Model Transformation Framework 1.0.0: Programmer's Guide, 2004,” at www.alphaworks.ibm.com/tech/mtf) and QVT Relations published by the OMG.
Another main category of transformations use graph rewriting rules in their specifications. Structured models are treated as typed, attributed and labeled graphs of elements. Transformation rules in this category have two sides: a left hand side (LHS) that expresses a pattern to be matched on the input model, and a right hand side (RHS) with another pattern to replace that of the LHS. Patterns of both sides are usually specified in the concrete syntax of the modeling languages at each side; an advantage to authors, who are usually familiar with those languages and not their abstract syntax (something often required in other approaches). Examples of approaches in this category include Fujaba by University of Paderborn Software Engineering and Attributed Graph Grammer.
Hybrid approaches also exist. Those are approaches where multiple strategies are used. For example QVT has three different languages: Relational, Operational and Core. Another approach is ATL (see F. Jouault and I. Kurtev, “Transforming Models with ATL,” Proc. of Model Transformations in Practice Workshop (MTIP), MoDELS, Montego Bay, Jamaica 2005), where rules can be fully declarative, fully imperative or a hybrid.